\documentclass{article}
\usepackage{geometry}
\usepackage{amsmath}
\geometry{  rmargin=.7in
           ,lmargin=.7in
           ,tmargin=.5in
           ,bmargin=.5in
         }

\begin{document}

\small
\pagestyle{empty}
\begin{minipage}{.5\textwidth}
\begin{flushleft}
\begin{tabular}{ll}
Presentation \#1 & \\  
& \\
& \\
& \\
\end{tabular}
\end{flushleft}
\end{minipage}
\begin{minipage}{.5\textwidth}
\begin{flushright}
  Dennis Castleberry  \\
  Sudip Biswas        \\
  Dr. Rajgopal Kannan \\
  CSC 7103:001        \\
  04 September 2011   \\
\end{flushright}
\end{minipage}

\begin{center}  \emph{Extensibility, Safety and Performance 
in the SPIN Operating System} by Bershad et al. \end{center}


This paper details the motivation, design, and performance analysis of an
extensible operating system called SPIN. Motivated by the often poor match
between application resource needs and OS interface and implentation, SPIN aims
to safely allow applications to modify the OS interface and implentation to
support application resource needs and to optimize application performance.
The OS achieves this through four techniques: (1) co-location, whereby OS
extensions are dynamically linked to the kernel virtual address space (KVAS);
(2) enforced modularity provided by the Modula-3 programming language; (3)
logical protection domains, within which extensions exist; and (4) dynamic call
binding, whereby extensions execute in response to system events such as page
faults or thread schedulings.  In combination, these techniques enable, with
low overhead, the definition of safe system services interface, thereby
enabling extensibility by defining the set of resources and operations made
available to applications.

The crux of the motivation for SPIN lies in the fact that specialization is
desired for some application sets, but is costly to achieve as well as
error-prone. Thus an extensible system which can be safely and dynamically
altered to meet the resource needs of an application with minimal effort would
be of great value. Prior efforts to build such extensible systems have revealed
a trichotomous tension among extensibility, safety, and performance. One
traditional approach has been through the use of microkernels, which enable
extension of nearly any kernel service; however, to match the specialized needs
of applications requires substantial re-writes to the microkernel code, and
such extensions suffer high communication overhead, thus limiting performance.
Another approach has used small languages to extend the OS interface through
code that runs in the kernel. Notwithstanding this, the language's narrowness
complicates the writing of control and data structures, limiting extensibility
and hampering integration; furthermore, interpretation overhead can limit
performance. Other projects use software fault isolation, which allows the safe
linking of application code into the KVAS; however, it may be unsuitable for a
system wherein extensions access a large number of segments. In summary, no
attempt has yielded a satisfactory reconciliation of these three needs.

The SPIN OS is structured in such a way as to offer extensibility and
performance without compromising safety. SPIN extensions are written in
Modula-3, which supports: interfaces, which enforce transparency of lower-level
items of a given module; type safety, which prevents code from accessing memory
arbitrarily; and automatic storage management, which ``prevents memory used by
a live pointer's referent from being returned to the heap and reused for an
object of a different type.'' The SPIN protection model consists of
capabilities, which provide fine-grained access control of resources to
extensions; and protection domains, ``which define the set of accessible names
available to an execution context.'' Names may be ``created, coordinated, and
linked in the context of protection domains.'' Domains are highly flexible;
they can intersect or be disjointed, allowing for the sharing of services or
creation of new ones. Extensions are defined in terms of events, i.e. messages
that indicate a change in the system; and handlers, which receive and act on
events. Using events to communicate among the system and extensions, SPIN
provides a set of core services to manage memory and processor resources. The
memory management system handles the allocation of virtual and physical
addresses and mappings between them via the physical address service, virtual
address service, and translation service, respectively. The translation service
contains events for memory management exceptions, e.g. an application
attempting to access unallocated memory. These services ``do not define an
address model directly, but can be used to implement a range of models using a
variety of optimization techniques.'' SPIN also allows an application to
provide its own thread package, which defines the application's execution model
and synchronization procedure; and scheduler, which controls processor
multiplexing across multiple threads. It does not define a thread model, but
rather a structure on which an implementation of a thread model may rest: a set
of events raised an handled by schedulers and thread packages. All in all, the
design lends to the safe extensibility of the OS; as well as to superior
performance.

The performance of SPIN is analyzed in comparison to the DEC OSF/1 V2.1
(monolithic OS) and Mach OS (microkernel) from four perspectives: system size,
microbenchmarks, networking, and end-to-end performance. The total source size
of the kernel amounts to shortly over 65,000 lines, $<811,000$ bytes of text, and
$<448,000$ bytes of data.  Protected communication overhead is measured in
microseconds for: protected in-kernel calls (.13), system calls (4), and
cross-address space calls (89); These are considerably smaller than for DEC
OSF/1 (n/a, 5, and 845, resp.) and Mach (n/a, 7, and 104, resp.). Thread
management overhead is divided into two operations: fork-join and ping-pong.
Each is considerably smaller for the SPIN kernel (22, 17) than for DEC (198,
21) or Mach (101, 71); in addition, for user application overhead, layered
(262, 159) and integrated (111, 85) are shorter than DEC (1230, 264) or Mach
(338, 115) with the sole exception of layered ping-pong overhead. Virtual
memory operation overheads in SPIN also soundly outperform those for DEC and
Mach for all operations. SPIN Ethernet latency (565) as well as ATM latency
(421) is shorter than for DEC Ethernet (789) or ATM (631). Bandwidth is
identical for Ethernet but for ATM, SPIN (33) outperforms DEC (27.9). In
addition, round-trip latencies for 16-packets sent through TCP and UDP are
shorter for SPIN than DEC. Furthermore, server CPU utilization for SPIN is less
than for DEC for any given number of clients connected. Thus, SPIN outperforms
the monolithic DEC OSF/1 and the Mach microkernel in all four domains.

In conclusion, motivated by the need for an extensible and high-performance but
safe operating system, the SPIN OS demonstrates a successful attempt to
reconcile such needs through the use of co-location, enforced modularity,
logical protection domains, and dynamic call binding. With extensibility and
safety are offered through its design characteristics, and a performance
analysis that reveals lower overhead and network latency than its monolithic
kernel and microkernel counterparts, SPIN soundly addresses these needs.

\end{document}
